Pídele a cualquier modelo de lenguaje un script rápido para quitar duplicados de un CSV y te devolverá Python. Pídele un ayudante de migración de usar y tirar y será Bash o Node. Casi nunca propondrá Rust para un proyecto de fin de semana, y con razón: compilar es lento, el directorio target/ se come decenas de gigas y el ciclo de «escribir, fallar con el borrow checker, corregir» alarga cada iteración. Ese mismo hecho es el punto de partida de un ensayo de David Lee publicado en Medium el 23 de octubre de 2026, que sostiene algo contraintuitivo: cuando generar código cuesta casi cero, que un proyecto esté escrito en Rust se convierte en una señal útil.
Conviene desarrollar la idea con más detalle, porque tiene una parte sólida y otra que necesita matices.
El contexto: Rust y la IA, en todas las charlas del año
La combinación de Rust e inteligencia artificial ha sido uno de los hilos de la temporada de conferencias. En RustConf 2026, celebrada del 8 al 11 de septiembre en Montreal, el programa incluyó la charla «Good or Bad Vibes? Coding with AI in Rust», que parte de una observación incómoda: los modelos recientes ya escriben Rust que compila y pasa los tests, pero los problemas de fondo pueden seguir ahí. Que el código compile ya no es garantía de que sea correcto, aunque sí es un listón más alto que en la mayoría de lenguajes.
La prueba de trabajo del código abierto
El argumento central es una analogía con la prueba de trabajo de Bitcoin. En esa red, el coste computacional no es un desperdicio: es lo que hace creíble el bloque. Aplicado al software, elegir un lenguaje caro de compilar y exigente de escribir funciona como un coste que alguien ha decidido asumir. Si el autor (y la herramienta de IA que lo acompaña) valoró las alternativas, consideró el precio y aun así eligió Rust, hay indicios de una apuesta a largo plazo.
Esto importa porque las señales superficiales se han devaluado. Un README pulido, una web de aterrizaje vistosa o un contador de estrellas se generan hoy en minutos. La oferta de proyectos es prácticamente infinita y casi todas las señales visibles son baratas. La que sigue costando es el mantenimiento sostenido: responder issues, publicar versiones, usar tu propia herramienta cada día.
Cuatro comprobaciones antes de adoptar un proyecto
- Historial de commits de los últimos 90 días, no el total de estrellas.
- Issues cerradas con una corrección real, no con un «gracias, lo miramos».
- Si el autor usa la herramienta a diario (dogfooding).
- Un calendario de versiones que sobreviva al anuncio de lanzamiento.
Ninguna de las cuatro se puede fingir con un prompt. Todas requieren tiempo.
Medio día para construirlo, un mes para sostenerlo
La asimetría real está entre escribir y poseer. Una herramienta de línea de comandos que sigue un fichero de log se genera en una tarde. Después llegan los casos límite: la rotación de logs rompe silenciosamente el descriptor de fichero, alguien abre un archivo de 2 GB y el programa intenta cargarlo entero, o en Windows las rutas se comportan de otra manera. Es una semana de trabajo solo para uso personal. En cuanto se comparte, hay que absorber los sistemas, locales y costumbres ajenos, y responder a la pregunta de si pierde memoria o llena el disco tras un mes en marcha.
En infraestructura es todavía más marcado. El fallo importante rara vez aparece el primer día; aparece el día 40: el mapa de seguimiento de conexiones que nunca expulsa entradas, o el descriptor de fichero que se escapa una vez por cada reconexión. La IA ha abaratado de forma radical escribir código. No ha tocado el coste de asumir sus consecuencias.
Dónde se paga el impuesto
Los lenguajes dinámicos llevan el coste del prototipo casi a cero y aplazan a producción el impuesto de la concurrencia, la memoria y los casos límite. Se paga más tarde, normalmente de madrugada. Rust cobra ese impuesto el primer día, y lo hace mediante el sistema de tipos:
- La propiedad obliga a decidir quién es dueño de cada búfer.
SendySyncobligan a decidir qué cruza hilos y cómo.- El
matchexhaustivo obliga a tratar todos los estados posibles. Resultsaca todas las rutas de error a la superficie.
Un ejemplo concreto: este código, típico de un primer borrador generado a toda prisa, no compila.
use std::rc::Rc;
use std::thread;
fn main() {
let datos = Rc::new(vec![1, 2, 3]);
let copia = Rc::clone(&datos);
// error[E0277]: `Rc<Vec<i32>>` cannot be sent between threads safely
let h = thread::spawn(move || println!("{:?}", copia));
h.join().unwrap();
}
El compilador rechaza el programa porque Rc no implementa Send: su contador de referencias no es atómico y compartirlo entre hilos provocaría una carrera de datos. La corrección es usar Arc. En Python o JavaScript el equivalente de ese error llegaría en producción, intermitente y difícil de reproducir.
Con los estados ocurre lo mismo. Si se añade una variante a un enum, todos los match que no la cubran dejan de compilar:
enum Conexion {
Abierta,
Cerrada,
Reconectando { intentos: u32 },
}
fn describir(c: &Conexion) -> String {
match c {
Conexion::Abierta => "abierta".into(),
Conexion::Cerrada => "cerrada".into(),
Conexion::Reconectando { intentos } => format!("reintento {intentos}"),
// Si falta una variante, el programa no compila.
}
}
Cada error del compilador es un contrato negociado de antemano en lugar de una incidencia negociada en producción. Hay además un efecto específico de la era de la IA: el Rust generado que compila ya ha pasado una revisión mecánica que el Python generado nunca recibe. Parte de la lentitud percibida al generar Rust es el compilador rechazando respuestas erróneas que otros lenguajes habrían dejado pasar sin protestar.
Lo que Rust no te da
El ensayo original, de hecho, es más optimista de lo que permite la evidencia en un punto: los fallos del «día 40» que cita como ejemplo no son de los que el compilador atrapa. En Rust, perder memoria es «seguro» desde el punto de vista del lenguaje. Un HashMap que nunca expulsa entradas compila sin una advertencia, igual que un ciclo de Rc o un descriptor que no se cierra porque alguien lo guardó en una estructura de larga vida. Lo que Rust elimina son las carreras de datos, el uso tras liberar y los accesos fuera de rango en código seguro, y obliga a que los errores sean visibles. La lógica incorrecta, las fugas por diseño y los bloques unsafe mal razonados siguen siendo responsabilidad humana.
El propio autor lo admite: es una señal, no una garantía. Existen repositorios Rust abandonados y mucho software excelente y duradero escrito en Go, Python o C. La prueba de trabajo demuestra esfuerzo, no calidad. Aun así, en un mundo saturado de código gratuito, el esfuerzo es el primer filtro que de verdad funciona.
No reinventes; y si lo haces, comprométete
La conclusión práctica del ensayo es sensata: salvo que no exista alternativa y dependas mucho de la herramienta, reconstruir algo rara vez compensa. Usa lo que está mantenido. Pero si la decisión es construirla uno mismo y elegir Rust, esa elección dice algo: hay una intención de ingeniería seria y duradera detrás.
Dos ejemplos de casa: mboxShell y CrawlForge
Dos proyectos de código abierto del equipo detrás de este medio encajan con esa lógica, y conviene presentarlos como lo que son: ejemplos propios, no pruebas independientes de la tesis.
mboxShell es un visor de ficheros MBOX para el terminal, con licencia MIT. Nació de un problema que un lenguaje con recolector de basura y carga ansiosa resuelve mal: abrir backups de Gmail Takeout de decenas de gigabytes. Usa lectura en streaming con un búfer de 1 MB y un índice persistente, de modo que un fichero de 100 GB consume prácticamente la misma memoria que uno de 1 GB, y se distribuye como binario único de unos 5 MB para Linux, macOS, Windows y FreeBSD. Es exactamente el tipo de herramienta en la que el caso del fichero de 2 GB del ensayo deja de ser una anécdota. Lo explicamos con detalle en el artículo sobre mboxShell. A fecha de 1 de noviembre de 2026 el repositorio tiene actividad reciente y la versión 1.2.1 se publicó el 31 de octubre.
CrawlForge es una herramienta de auditoría SEO técnica con licencia Apache-2.0, pensada para quien gestiona muchos sitios y no solo uno. Rastrea un sitio, evalúa decenas de reglas de auditoría (indexabilidad, códigos HTTP, metadatos, canónicas, contenido, recursos y hreflang) y lo vuelca todo a un único fichero SQLite. Su función más útil es la comparación: crawlforge diff antes.sqlite despues.sqlite indica qué mejoró y qué empeoró entre dos rastreos, y con --fail-on high puede actuar como puerta en integración continua. Los números que publica van con su método: 487.621 URLs en un solo rastreo con memoria estable, con un pico de 259 MB, y cero diferencias de extracción en 1.800 comparaciones frente a otro rastreador consolidado. También documenta lo que no hace: no renderiza JavaScript ni comprueba enlaces externos. Esa transparencia sobre las limitaciones es, precisamente, el tipo de señal de mantenimiento que el ensayo propone buscar.
Ninguno de los dos se escribió en un fin de semana ni se eligió Rust por moda. Son herramientas de larga vida, con un coste de propiedad asumido de antemano, y ahí es donde la tesis del ensayo se ve con más claridad.
Resumen
En una era de código barato e ilimitado, solo dos cosas conservan valor: la determinación de mantener algo y las garantías aplicadas en tiempo de compilación. Rust no las ofrece por sí solo, pero es uno de los pocos sitios donde las dos suelen aparecer en el mismo repositorio. Antes de adoptar una dependencia, mira cuándo fue el último commit, cómo responden a los issues y qué dicen sobre lo que no hacen. El lenguaje es solo parte de la señal.
Fuente original del planteamiento: «AI Will Never Recommend Rust for Your Weekend Project. That's the Point.», de David Lee (Medium, 23 de octubre de 2026).
Imagen: Pexels / Cheyenne Olander